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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


The PPP Encryption Control Protocol (ECP) [2] provides a method to 
negotiate and utilize encryption protocols over PPP encapsulated 


links. 


This document provides specific details for the use of the Triple-DES 
standard (3DES) [6] for encrypting PPP encapsulated packets. 


Table of Contents 


T PTV EIAO. CL SEL OMA.» sere a ah O E E a a i E EE a eked a aS 2 
Viel, ALgorrithm s 4 syst Seve onti aea FSC ae ee a O eee eee 2 
T25, Keys go ieo one vet Giada ses overeat aa Wie Sie ede Ge aie ieee gate eos la eu ee eels Je Sue 3 
2. 3DESE,-Contirguration: Option: -For EHCP Gorse ssc eee ale tds oes 3 
3. Packet: format. FOr 3DESE so sieeete dee Ge eee be oe eee dee We eee be es 4 
4. PNGIEY PE LOM: areena aaen oo isan a a a a lea e ar aeGne Orla a a n a tisk 5 
Are Le! © Padding adroot a sa asada Se casa Gila Mev ant a a wi a acai ighte ar onder taua® weet sete en aes 5 
4:2 Recovery after packet. LOSS. rasas an dred eg ale dcere Slee, oles rare ey aleve 6 
Ss Security s\CONSTAECTACTONS. sere siele eee See Sele a a Gee EO eS 6 
6. REFEFENCES: matea Ace bes ete ae She wees See Sted Ge ee cede oe ES ie Boe 7 
Ds ACKAOWLEAOGEMENES: 9 2-4. Sone ie 8. ciate: E ee rede eiceh ale aa teehee: i srente, exer a 7 
8. Aüthor s VADGHE S'S See isis eon eee ese ie ei eee Shee ea hee tiene Se eee ee ae 7 
9. Ruld -Copyright Statement 2. si3-.05 saree sl S78 eae heehee ole ele ary eee es 8 


Kummert Standards Track [Page 1] 


RFC 2420 PPP Triple-DES Encryption September 1998 


Le 


t 


Introduction 


The purpose of encrypting packets exchanged between two PPP 
implementations is to attempt to insure the privacy of communication 
conducted via the two implementations. There exists a large variety 
of encryption algorithms, where one is the DES algorithm. The DES 
encryption algorithm is a well studied, understood and widely 
implemented encryption algorithm. Triple-DES means that this 
algorithm is applied three times on the data to be encrypted before 
it is sent over the line. The variant used is the DES-EDE3-CBC, which 
is described in more detail in the text. It was also chosen to be 
applied in the security section of IP [5]. 


This document shows how to send via the Triple-DES algorithm 
encrypted packets over a point-to-point-link. It lies in the context 
of the generic PPP Encryption Control Protocol [2]. 


Because of the use of the CBC-mode a sequence number is provided to 
ensure the right order of transmitted packets. So lost packets can be 
detected. 


The padding section reflects the result of the discussion on this 
topic on the ppp mailing list. 


In this document, the key words "MUST", "SHOULD", and "recommended" 
are to be interpreted as described in [3]. 


1 Algorithm 


The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC 
algorithm. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR’d 
with the first 64-bit (8 octet) plaintext block (P1). The keyed DES 
function is iterated three times, an encryption (E) followed by a 
decryption (D) followed by an encryption (E), and generates the 
ciphertext (C1) for the block. Each iteration uses an independent 
key: k1, k2 and k3. 


For successive blocks, the previous ciphertext block is XOR’d with 
the current 8-octet plaintext block (Pi). The keyed DES-EDE3 
encryption function generates the ciphertext (Ci) for that block. 
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Pl P2 Pi 
| | | 
IV---> (X) $o----- > (X) +-------- > (X) 
+----- | +----- + | +----—- + 
k1->| E | k1->| E | k1->| E | 
+----—- | +----- + +----—- + 
| | | | 
vV | vV : vV 
+----- 3 +----- + A +----- + 
k2->| D | k2->| D | | k2->| D | 
+----—- | +----- + | +----- + 
| | | | | 
+----- + | +----- + | +----—- + 
k3->| E | k3->| E | k3->| E | 
+----- + +----- + +----- + 
| | | | | 
+---->+ +------ >+ +----> 
| | | 
G1 C2 Ci 


the order of the functions is reversed: decrypt with k3, 
decrypt with k1, and XOR with the previous cipher- 


To decrypt, 
encrypt with k2, 
text block. 

k2 and k3) DES-EDE3-CBC is 


When all three keys (kl, are the same, 


equivalent to DES-CBC. 
1.2 Keys 
The secret DES-EDE3 key shared between the communicating parties is 
effectively 168-bits long. This key consists of three independent 
56-bit quantities used by the DES algorithm. Each of the three 56- 
bit subkeys is stored as a 64-bit (8 octet) quantity, with the least 
significant bit of each octet used as a parity bit. 


When configuring keys for 3DESE those with incorrect parity or so- 
called weak keys [6] SHOULD be rejected. 


2. 3DESE Configuration Option for ECP 
Description 


The ECP 3DESE Configuration Option indicates that the issuing 
implementation is offering to employ this specification for 
decrypting communications on the link, and may be thought of as 
a request for its peer to encrypt packets in this manner. The 
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ECP 3DESE Configuration Option has the following fields, which 
are transmitted from left to right: 


Figure 1: ECP 3DESE Configuration Option 


0 1 2 3 
0. 1-2-3496 B88 9 Or T 3 A BAGAT E OO: Ae 2-3) AS59628 Oe 0° 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Initial Nonce .. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 

2, to indicate the 3DESE protocol. 
Length 


10 
Initial Nonce 
This field is an 8 byte quantity which is used by the peer 
implementation to encrypt the first packet transmitted 
after the sender reaches the opened state. To guard 
against replay attacks, the implementation SHOULD offer a 
different value during each ECP negotiation. 
3. Packet format for 3DESE 


Description 


The 3DESE packets that contain the encrypted payload have the 
following fields: 


Figure 2: 3DESE Encryption Protocol Packet Format 


0 1 2 3 
01234567890123456789012345678901 
tata ta tata taeta tata tata tata tata ta tata tatatatatatatatatatatatat—t-t 
| Address | Control | 0000 | Protocol ID | 
tata ta tata ta—ta tata tata tata tata ta tata ta ta tata tata tata tata tatatat-t 
| Seq. No. High | Seq. No. Low | Ciphertext 

Fata ta tatata—ta tata tata ta tata ta ta tata tatatatatatatatatatatatat-t-t 


Address and Control 


These fields MUST be present unless the PPP Address and 
Control Field Compression option (ACFC) has been 
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negotiated. 
Protocol ID 


The value of this field is 0x53 or 0x55; the latter 
indicates the use of the Individual Link Encryption 
Control Protocol and that the ciphertext contains a 
Multilink fragment. Protocol Field Compression MAY be 
applied to the leading zero if negotiated. 


Sequence Number 


These 16-bit numbers are assigned by the encryptor 
sequentially starting with 0 (for the first packet 
transmitted once ECP has reached the opened state). 


Ciphertext 


The generation of this data is described in the next 
section. 


4. Encryption 


Once the ECP has reached the Opened state, the sender MUST NOT apply 
the encryption procedure to LCP packets nor ECP packets. 


If the async control character map option has been negotiated on the 
link, the sender applies mapping after the encryption algorithm has 
been run. 


The encryption algorithm is generally to pad the Protocol and 
Information fields of a PPP packet to some multiple of 8 bytes, and 
apply 3DES as described in section 1.1 with the three 56-bit keys kl, 
k2 and k3. 


The encryption procedure is only applied to that portion of the 
packet excluding the address and control field. 


When encrypting the first packet after ECP stepped into opened state 
the Initial Nonce is encrypted via 3DES-algorithm before its use. 


4.1 Padding 


Since the 3DES algorithm operates on blocks of 8 octets, plain text 
packets which are of length not a multiple of 8 octets must be padded 
prior to encrypting. If this padding is not removed after decryption 
this can be injurious to the interpretation of some protocols which 
do not contain an explicit length field in their protocol headers. 
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Therefore all packets not already a multiple of eight bytes in length 
MUST be padded prior to encrypting using the unambiguous technique of 
Self Describing Padding with a Maximum Pad Value (MPV) of 8. This 
means that the plain text is padded with the sequence of octets 1, 2, 
3, .. 7 since its length is a multiple of 8 octets. Negotiation of 
SDP is not needed. Negotiation of the LCP Self Describing Option may 
be negotiated independently to solve an orthogonal problem. 


Plain text which length is already a multiple of 8 octets may require 
padding with a further 8 octets (1, 2, 3 ... 8). These additional 
octets MUST only be appended, if the last octet of the plain text had 
a value of 8 or less. 


When using Multilink and encrypting on individual links it is 
recommended that all non-terminating fragments have a length 
divisible by 8. So no additional padding is needed on those 
fragments. 


After the peer has decrypted the ciphertext, it strips off the Self 
Describing Padding octets to recreate the original plain text. The 
peer SHOULD discard the frame if the octets forming the padding do 
not match the Self Describing Padding scheme just described. 


Note that after decrypting, only the content of the last byte needs 
to be examined to determine the presence or absence of a Self 
Described Pad. 


4.2 Recovery after packet loss 


Packet loss is detected when there is a discontinuity in the sequence 
numbers of consecutive packets. Suppose packet number N - 1 has an 
unrecoverable error or is otherwise lost, but packets N and N + 1 are 
received correctly. 


Since the previously described algorithm requires the last Ci of 
packet N - 1 to decrypt Cl of packet N, it will be impossible to 
decrypt packet N. However, all packets N + 1 and following can be 
decrypted in the usual way, since all that is required is the last 
block of ciphertext of the previous packet (in this case packet N, 
which WAS received). 


5. Security Considerations 


This proposal is concerned with providing confidentiality solely. It 
does not describe any mechanisms for integrity, authentication or 
nonrepudiation. It does not guarantee that any message received has 
not been modified in transit through replay, cut-and-paste or active 
tampering. It does not provide authentication of the source of any 
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packet received, or protect against the sender of any packet denying 
its authorship. 


Security issues are the primary subject of this memo. This proposal 
relies on exterior and unspecified methods for retrieval of shared 
secrets. It proposes no new technology for privacy, but merely 
describes a convention for the application of the 3DES cipher to data 
transmission between PPP implementations. Any methodology for the 
protection and retrieval of shared secrets, and any limitations of 
the 3DES cipher are relevant to the use described here. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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